The present invention is related to computer-system security. A large effort is currently underway in the computing industry to provide secure computer systems to facilitate electronic commerce, storage of confidential information in commercial and governmental institutions, secure communications, and for facilitating construction of highly available, tamper-proof computer systems. FIG. 1 is a block diagram of a number of important components within a single-processor computer-hardware platform. The hardware platform 101 includes a processor 103, random-access memory 105, and non-volatile data storage, such as a hard disk drive 107. The processor stores and retrieves data from memory 105 via a high-speed system bus 109. The high-speed system bus is interconnected to one or more lower-speed peripheral busses 111 via a system controller 113. A non-volatile data-storage controller 115 is connected to the peripheral bus 111 as well as to an input/output (“I/O”) bus 117 which is connected to the non-volatile data-storage device 107. Additional I/O controllers, such as I/O controller 119, maybe connected to the one or more peripheral busses 111.
During operation, computer programs migrate from the mass-storage device or devices 107 to system memory 105, from where they are executed by the processor 103. Computer programs may also be received by an I/O controller from external devices and moved to system memory 105, from where they are executed by the processor 103. Initially, following power on of the computer system, the processor 103 may begin to execute instructions for a boot program stored in a small, non-volatile memory, such as a flash memory or other read-only memory constituting one or more integrated circuits. The manufacturer of a computer system may use various security techniques, such as digital signatures or other cryptography techniques, to ensure that only trusted, verified boot programs are executed by the processor. At a certain point during the boot process, the small boot program stored within a read-only memory device must begin to verify and then execute larger programs stored on one or more mass-storage devices, such as mass-storage device 107. Again, various security techniques, including cryptography techniques, can be used to continue a chain of trust by which each next-to-be-executed program is first verified by programs already loaded and executed. By this means, the computer system can be brought to life, in stages, following power-on or reset, in a secure fashion.
FIG. 2 is a flow-control diagram that illustrates a fundamental problem in secure computing. Following power on or reset, as described above, the computer system reads a trusted boot program from a read-only memory device and executes that trusted boot program in the initial stages of the boot process in step 202. Next, in step 204, the initially loaded boot program begins to control the hardware system to locate and move other trusted programs from one or more mass-storage devices into system memory for execution. As discussed above, this process may be continued to slowly build up a constellation of core executable programs necessary for operation of the computer system. Finally, a secure kernel may be fully loaded, following which one or more operating systems are loaded and launched, resulting in a useable, fully functioning computer system, with the secure kernel providing a secure interface through which one or more operating systems access system resources. In general, the operating system needs also to be secure, although an operating system may not need to be computationally verified, as necessary for secure kernels.
Although the above-described secure boot process is generally undertaken to bring the system to a fully functional and secure state, there are situations when it is desirable to launch programs that are not secure. For example, a system administrator may desire to boot the system up to a minimal level of functionality, and to then run a suite of diagnostics or administrative tools that are not secure, and then reboot the system. However, the ability to run unsecured programs necessitates that secure programs be provided insecure-state-sensing or insecure-state-sensing-and-disabling mechanisms, so that, for example, a secure boot is not continued or launched following execution of unsecured programs or routines. Otherwise, the carefully constructed chain of trust established by secure boot procedures may be thwarted.
Returning to FIG. 2, at some point during system initialization, an administrator may choose to load and execute untrusted, or, in other words, non-verified software programs, as shown in step 206. The system administrator should then perform a hard reset and reboot the system. However, a secure computer system cannot depend on human users to properly execute security procedures, because human users can easily forget to do so. Assuming that the system is not reset and rebooted following running of untrusted software, in step 206, then later, as shown in step 208, a secure boot program, operating system, or other secure program may be invoked or continued, but should not carry out operations that would expose secure data or invoke secure routines when the computer system is currently insecure. In certain sophisticated systems, rather than a binary differential between an absolutely secure state and an insecure state, a computer system may reside in a number of states associated with increasing security levels, from as insecure state through various partially secure states up to a secure state. For example, a system that has booted a third-party operating system may not be absolutely secure, but may be more secure than a system that has run one or more third-party application programs, or that has exchanged data with external devices via a communications medium. Should the program, in step 208, be constructed to employ security-state-sensing-and-disabling mechanisms, when the program undertakes some secure action, such as storing encryption keys, the security-state-sensing-and-disabling mechanisms may detect and prevent continued execution or operations that would result in compromising secure data. Additional software programs may run, as shown in step 210. Somewhat later, the same program that ran in step 208, or another, similar program, may run, in step 212, and may need to again be protected from carrying out operations that could compromise or expose secure data, or subsequent secure operation of the computer system. For example, the computer program running in step 212 may need to retrieve stored encryption keys, without fear that, by doing so, the program may expose the encryption keys to eavesdropping software agents or other malicious, untrusted processes running within the computer system. In general, the security state may only decrease in security following initialization.
Thus, a central problem in secure computing, as illustrated in FIG. 2, is the problem of reliably detecting insecure or partially secure states of a computer system at various points in time and preventing security-assuming operations from being carried out in insecure states, or, to be more exact, in states less secure than the security level assumed by a program for carrying out the operations. The problem is not trivial. In general, once any non-trusted software is executed, it is difficult for subsequent processes to determine the security state of a computer system without relying on some independent, trusted processing entity that can monitor the security state of the computer system. FIGS. 3 and 4 illustrate one technique for monitoring the security state of the computer system currently promulgated by the trusted computing organization. As shown in FIG. 3, a trusted processing component provided by the Trusted Computing Platform Alliance (“TCPA”), called the trusted platform module (“TPM”) 302, is added to the computer system. The TPM is an independent security-state monitor that provides, among other things, a simple interface to allow software processes to securely encrypt and decrypt data without risk of exposing encryption keys to malicious processes.
FIG. 4 illustrates the basic interface provided by a TPM. As shown in FIG. 4, the TPM 302 includes a processor 402, internal memory that stores security-state information representing the security state of the computer system 404, and internal memory 406 that stores private encryption keys used by the TPM to support the interface provided by the TPM to external processes. That interface includes three basic operations, illustrated in FIG. 4. First, an external process may transmit a current-state request 408 to the TPM and receive a response that includes an encapsulation of the current security state of the computer system 410. An external process may transmit a seal request 412, containing data that the external process wishes to protect 414, to the TPM which encrypts the data and returns to the external process a response 416 that includes the encrypted data 418. An external process may transmit an unseal request 420, containing encrypted data 424 previously encrypted by the TPM, to the TPM and receive a response 426 that includes the corresponding decrypted, or plain-text data 428. Thus, the TPM serves as a trusted data security device and security-state monitoring device. The TPM constantly monitors the state of the computer system by receiving metrics from components of the computer system and determining a current security state of the computer system by processing received metrics. Various types of metrics may be employed, including the contents of system memory, various hardware registers, and other components of the current, dynamic state of the computer system.
While the TPM can monitor the security state of a computer system, and report the current security state, the TPM provides for essentially 2160 possible security states, and even slight changes to the computational state of the computer system may lead to the TPM assigning a new security state to the computer system, depending, of course, on whether any of the slight changes impact the values of the metrics employed by the TPM to compute the current security state. Each time the security state changes, it may be difficult or impossible for secure data associated with a previous, more secure state to ever again be accessed. The TPM device is complex and adds expense to computer systems, and there are currently no provisions in the TPM standard for directly exporting security-state signals to other hardware components of a secure computer system, such as the system firmware refresh circuitry.
For all of these reasons, designers, manufacturers, and users of secure computer systems have recognized the need for a relatively simple, inexpensive, but reliable and computationally secure hardware entity and associated methodology for sensing the current security state of a computer system and preventing programs and routines executing on the computer system from carrying out operations incompatible with the current security state.